[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IESG comments on generalize MPLS documents

At 10:47 AM 8/27/2002, Wijnen, Bert (Bert) wrote:


Inline
> > > >6. From section 9.1.1 towards the end, I get the impression
> > > >    that [MPLS-UNNUM] is normative too? Status?
> > >
> > > one reference has been removed, the other is still there.  I think
> > > informative is accurate for the new text.
> > >
> >Will check when I see the text
>
>              IP Address: 32 bits
>
>                 The IP address field may carry either an IP address of a
>                 link, or an IP address associated with the router ID,
>                 where router ID may be the value carried in the router ID
>                 TLV of routing.
>
>              Interface ID: 32 bits
>
>                 For type 3 usage, the Interface ID carries an interface
>                 identifier, see [MPLS-UNNUM].
>

that to me seems to make it normative, no?
GMPLS can be implemented without unnumbered interfaces support. Normative implies otherwise.

>                 For types 4 and 5, the Interface ID indicates a bundled
>                 component link.  The special value 0xFFFFFFFF can be used
>                 to indicate the same label is to be valid across all
>                 component links.
>
>
> > > >some less serious, but now that you are at it anyway...
> > > >
> > > >7. Intro lists 4 types of interfaces (PSC, TDM, LSC, PSC)
> > > >    Architecture doc (still and I-D) lists L2SC as well.
> > > >    Would it not be better if they are in sync?
> > >
> > > L2SC is really a sub/special-case of PSC.  Other documents also don't
> > > explicitly call it out.
> > >
> >The Architecture doc DOES spell it out.
> >When I read "Architecture" then I always think it is guiding any other
> >documents in that space.
>
> If this is a "less serious" comment, then I can use my judgement as
> editor.  (which I've done.) If this an IESG requirement then I'll make
> whatever change is required.  Is there a required change from
> the IESG here?

Nope... I was just doing due dilligence trying to get consistency in the
whole set of documents. This for the better of the intended audience.
But you seem to take the editorial liberty to ignore your audience.

>
> >[...]
> > > >
> > > >
> > > >13. the document could have been 5 pages shorter if it had not
> > > >     bothered to explain how it is different from "old" MPLS,
> > > >     and just concentrated on what it was doing.
> > > >     I guess a ptr to the old MPLS doc would have been sufficient?
> > >
> > > I think we should just keep this as is.
> > >
> >So you are asking me to defend that in the IESG.
> >Not sure how successfull I will be. Up to you to take the risk
> >
>
> same comment.  Is there a required change from the IESG here?
>
Same comment. IESG member(s) had suggested this as a way to make the
document faster to read (with a ptr to the MPLS doc that described
the "old" MPLS. If you prefer to waste more bytes on the wire when people
download the doc, or to waiste more trees when they print it...
That I guess is again your editorial liberty.
okay will leave unchanged. BTW - There seems to be a contradictory message here. Previous comment was add more context/background, this one says remove context/background...

> > > >14. Cannot implement section 9 (interface identification) - the
> > > >     info on which end's interfaces are being talked about, and
> > > >     how one end identifies which of its interfaces match
> > > >     corresponding interfaces at the other end simply doesn't
> > > >     seem to be there.
> > > >     (generalized-rsvp-te specifies that the downstream interface
> > > >      is sent in a PATH message.....this is a matchup, but not sure
> > > >      which way it matches).
> > >
> > > The whole document can only be implemented when combined with
> > > one of the  protocol specific documents.   I think the 21 responses
> > > to the implementation survey speaks for itself.  (Also, this
> > > document does clearly  states: "In all cases the choice of the data
> > > interface is indicated by the upstream node using addresses and
> > > identifiers used by the upstream node.")
> > >
> >So maybe adding a note to it to explain that might alleviate the
> >concern. Of course I can try to defend based on the 21 responses,
> >that is indeed a strong point. But often adding a one or wto line
> >explanation helps to fuse the push back
>
> I'm happy to do this.  I went to add more text and found the text that I
> was going to add was already present.  Please propose some text and it'll
> be included.
>
So what is the text that you think makes it clear enough?
1) "In all cases the choice of the data interface is indicated by the upstream node using addresses and identifiers used by the upstream node."

2a) For RSVP:

8.1. Interface Identification

The choice of the data interface to use is always made by the sender
of the Path message. The choice of the data interface is indicated by
the sender of the Path message by including the data channel's
interface identifier in the message using a new RSVP_HOP object sub-
type. For bidirectional LSPs, the sender chooses the data interface
in each direction. In all cases but bundling, the upstream interface
is implied by the downstream interface. For bundling, the path
sender explicitly identifies the component interface used in each
direction. The new RSVP_HOP object is used in Resv message to
indicate the downstream node's usage of the indicated interface(s).

and in section 8.1.2.

... Data channels are specified from the viewpoint of the
sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be
used when no TLVs are needed.

A node receiving one or more TLVs in a Path message saves their
values and returns them in the HOP objects of subsequent Resv
messages sent to the node that originated the TLVs.

2b) for LDP:

8.1. Interface Identification

The choice of the data interface to use is always made by the sender
of the REQUEST message. The choice of the data interface is indicated
by the sender of the REQUEST message by including the data channel's
interface identifier in the message using a new Interface TLV. type.
For bidirectional LSPs, the sender chooses the data interface in each
direction. In all cases but bundling, the upstream interface is
implied by the downstream interface. For bundling, the REQUEST
sender explicitly identifies the component interface used in each
direction.

and in section 8.1.2. (was mislabeled 8.2 in rev 06)

... Data channels are specified from the
viewpoint of the sender of a REQUEST message. The IF_ID TLV SHOULD
NOT be used when no TLVs are needed.

A node receiving one or more IF_ID TLVs in a REQUEST message saves
their values and returns them in the subsequent MAPPING message sent
to the node that originated the TLVs.



> >[...]
> > >
> > > ><draft-ietf-mpls-generalized-cr-ldp-06.txt>
> > > >
> > > >1. IANA asks:
> > > > Seems OK but which registry should these assignments
> > > > be going in.
> > > > So please specify.
> > >
> > > Took me a second to figure out what was needed here, the
> > > reference was
> > > broken (said 3031 not 3036.) With a proper reference, the registry
> > >
> >
> (<<http://www.iana.org/assignments/ldp-namespaces>http://www.iana.org/assignments/ldp-namespaces>
> > should be clear.
> > >
> >I would strongly recommend to also add that web ptr. It will Help
> >IANA a lot, and it will just smooth the further processing of the
> >document. It also helps later readers to quickly find the place
> >where values are registered.
>
> My understanding is that URLs are discouraged in RFCs, but if
> that's what the IESG want's...
>
Well, we do prefer to not have (unstable) URLs in the references section.
Otherwise just say ldp-namesapces.
The IANA URLs are pretty stable (we believe).
New text:

12. IANA Considerations

   This draft uses the LDP [RFC3036] name spaces, see
   http://www.iana.org/assignments/ldp-namespaces, which require
   assignment for the following TLVs:



> > > >4. IANA Considerations starts with:
> > > >      This draft uses the LDP [RFC 3031] name spaces, which require
> > > >      assignment for the following TLVs.
> > > >    Do you mean to reference 3036 instead of 3031?
> > > >
> > >
> > > yes.  same issue as comment 1.
> > >
> >same as above. pls add the web ptr to the registry
>
> sure, it's the same sentence (do you want it twice?)
>
Nope... not if it is in same doc, in same section.
I thinbk you know what I mean. You want to help the IANA
function to be able to quickly find the proper place to
do assignments. You should not assume IANA knows all the
ins and out of all the name-spaces by head.
..

see above.


> > > >1. This doc says "just use IPsec".  A clearer statement is needed,
> > > >    specifying the necessary IPsec selectors (per RFC 2401) and the
> > > >    way the cryptographically protected endpoints are related to
> > > >    the authorization model, i.e., who can do what.
> > >
> > > can you provide an example of what you'd like to see?
> > >
> >
> >I am checking with Security ADs.
>
> thanks.
>
no answer yet, will forward as soon as I have it.
Also feel free to check with SEC ADs Steve Bellovin and Jeff Schiller
yourself, then I do not have to function as a smtp relay

will do.  Didn't know the comment originated with them.

Lou


...

Bert