Re: Resolving "Enhancements" text...

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

John,

I agree it is more work to support two generalized label request formats.
I would like to see just one format.  To achieve this goal, we must find
a format that has fields which have general use, and allow them to be used
as needed by different network layers (networking technologies) as is
appropriate to their specific needs.

The type 5 format supports this.  It only includes "SONET unique stuff"
when it is being used for SONET.  The fields are all generally useful and
appropriate codepoints can be defined for them for each networking technology.

I have also suggested allowing independent codespaces for the fields by
technology (as indicated by the LSP Encoding Type) so that definition of
specific codepoints and semantics for different technologies can be done 
independently.  This would allow relatively independent progress to be
made in each networing technology.

I think we should take this to the general mailing lists so that everyone 
who is interested can comment or follow the discussion.

Regards,
Ben

jdrake@calient.net wrote:
> 
> Ayan and Greg,
> 
> What is the rule used by an origin node to decide whether to include a
> C_Type 4 or C_Type 5 Generalized Label Request in the Path message?
> 
> For example, suppose a router wants to set up a PSC LSP to another router
> across a set of SONET switches.  The link between the origin router and the
> origin SONET switch will be PSC at the router end and TSC at the SONET
> switch end.  If that router wants an OC-48 LSP but the link between it and
> the SONET switch is an OC-192, then the router is clearly going to be
> getting timeslot labels from the SONET switch.  So should the router use a
> type 4 or type 5 label request?
> 
> If the origin router sends a type 4, does the origin SONET switch convert it
> to a type 5 to transit the set of SONET switches and then does the
> destination SONET switch convert back to a type 4 before sending it to the
> destination router?  Conversely, why would the origin and destination
> routers want to deal with a type 5, since it contains all the SONET unique
> stuff that routers don't care about?
> 
> Another way of saying this is that while it might have seemed that we were
> finessing the issue by having two C_Types, it may end up being more work for
> everyone if we all have to support both.  Further, if the origin and
> destination routers have to deal with a type 5, they may want to have a lot
> more say over what's included in it.  Similarly, if we're providing a
> grooming function between OC-48 trails and OC-192 trunks and we're told that
> we have to use a type 5, we may want to have a lot more say about what's
> included in it.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Ayan Banerjee
> Sent: Wednesday, January 24, 2001 3:06 PM
> To: fubar@labn.net
> Cc: Ben.Mack-Crane@tellabs.com; JConnell@WhiteRockNetworks.com;
> Jzyu@zaffire.com; schatterjee@WhiteRockNetworks.com
> Subject: RE: Resolving "Enhancements" text...
> 
> All,
> 
> Greg and I have been working on the IETF GMPLS draft to
> resolve the outstanding issues. The modifications attached
> below are to the appropriate sections of
> draft-ietf-mpls-generalized-signaling-00.txt.
> 
> The proposed changes harmonizes those issues and
> are:
> 
> (a) Removed RT from the SONET/SDH label
> (b) Added Signal Type to the SONET/SDH label
> (c) Added a new field called LSP Protection Type
> (d) Reorganized the layout of some fields for label type 5.
> 
> We are hoping that this will bring about a closure to the
> various issues. Comments ?
> 
> Thanks,
> Greg and Ayan