Subject: Re: [mpls] Further updates reference for Bundling draft

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 29 Nov 2004 16:17:48 +0000

> > > >Looking at section 4 of RFC3946, I think you are updating some of 
> > > >this text, too.
> >I meant RFC3945.
> >Guess I got excited by all those new CCAMP RFCs. 
>
> Good, now we're down to a sensible section and document!  So what do you 
> see is being modified by the bundling draft?

Well, I admit you have to read as far as the second paragraph... 

  The concept of link bundling is essential in certain networks
  employing the GMPLS control plane as is defined in [BUNDLE].  A
  typical example is an optical meshed network where adjacent optical
  cross-connects (LSRs) are connected by several hundreds of parallel
  wavelengths.  In this network, consider the application of link state
  routing protocols, like OSPF or IS-IS, with suitable extensions for
  resource discovery and dynamic route computation.  Each wavelength
  must be advertised separately to be used, except if link bundling is
  used. 

  When a pair of LSRs is connected by multiple links, it is possible to
  advertise several (or all) of these links as a single link into OSPF
  and/or IS-IS.  This process is called link bundling, or just
  bundling.  The resulting logical link is called a bundled link as its
  physical links are called component links (and are identified by
  interface indexes).
## - Component links are not identified (externally) as interface indexes
##   but using the new identification rules in your revised text 

  The result is that a combination of three identifiers ((bundled) link
  identifier, component link identifier, label) is sufficient to
  unambiguously identify the appropriate resources used by an LSP.
## - The listed triplet may be "sufficient" but it is now more than
##   necessary. 

And then again in section 4.3.3
  With this mechanism, each component link that is unnumbered is
  assigned a unique Interface Identifier (32 bits value).  The upstream
  node indicates the choice of the component link by including a new
  IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message
  (see [RFC3473]/[RFC3472], respectively).
## - We have now specified the definition/scope of "unique" and h 

Nothing here is a big deal. just making an observation. 

Cheers,
Adrian

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Lou Berger <[email-masked]>
Date: Mon, 29 Nov 2004 12:01:44 -0500

>Nothing here is a big deal. just making an observation.

okay, I now understand your comment.  I think most, if not all of the 
comments you make hold true with the old version of the bundle draft as 
well.  (Hence my confusion).  Also I think your comments apply more 
to  implementation and doesn't alter the architecture.

As you say, isn't much of a big deal, so I think we should just leave as is...

Lou